OpenClaw 이후 등장하는 새로운 AI 아키텍처

최근 AI Agent 프로젝트들을 보면 재미있는 공통점이 하나 있습니다.

처음에는 대부분 이렇게 시작합니다.

User
↓
LLM
↓
Tools
↓
Real Computer

즉 AI가 실제 컴퓨터를 조작하는 구조입니다.

• - 브라우저를 열고

• - 버튼을 클릭하고

• - 파일을 생성하고

• - 프로그램을 실행합니다.

OpenClaw 같은 프로젝트가 바로 이런 구조입니다.

처음 보면 꽤 강력해 보입니다.

하지만 실제로 사용해보면 개발자들이 거의 항상 같은 결론에 도달합니다.

“이걸 실제 컴퓨터에서 돌리면 너무 복잡하다.”

Agent가 직접 컴퓨터를 쓰면 생기는 문제

AI가 실제 컴퓨터를 사용하면 처음에는 편합니다.

예를 들어 이런 요청을 할 수 있습니다.

이 사이트에서 데이터 가져와서 엑셀로 정리해줘

Agent는 이렇게 행동합니다.

브라우저 열기
→ 사이트 접속
→ 데이터 복사
→ Excel 실행
→ 파일 저장

문제는 이 방식이 생각보다 불안정하다는 것입니다.

예를 들어 이런 상황이 발생합니다.

• - 브라우저 UI가 변경됨

• - 로그인 세션 만료

• - 프로그램 버전 충돌

• - OS 권한 문제

결국 개발자들이 깨닫는 것은 이것입니다.

“AI에게 현실의 컴퓨터를 맡기는 건 생각보다 복잡하다.”

그래서 등장하는 해결책이 바로 Virtual Computer입니다.

실제 컴퓨터와 Virtual Computer에서 돌리는거랑 뭐가 차이가 나?

Virtual Computer는 간단히 말하면

환경변수가 통제되는 AI 전용 컴퓨터 환경입니다.

구조는 보통 이렇게 됩니다.

User
↓
Agent
↓
LLM
↓
Virtual Computer
↓
Browser / Apps / Tools

즉 AI는 실제 컴퓨터가 아니라 가상 컴퓨터를 사용합니다.

이 구조의 장점은 명확합니다.

1. 환경을 완전히 통제할 수 있다

Virtual Computer는 항상 같은 환경입니다.

예를 들어

Ubuntu 22
Chrome version fixed
Python environment fixed

이렇게 설정할 수 있습니다.

그래서 Agent가 항상 같은 UI , 항상 같은 프로그램을 사용하게 됩니다.

AI에게는 이런 예측 가능한 환경이 매우 중요합니다.

2. Agent를 복제할 수 있다

Virtual 환경의 또 다른 장점은 복제 가능성입니다.

예를 들어

AI researcher agent
AI marketing agent
AI devops agent

각각의 Agent가 자기 전용 컴퓨터를 가질 수 있습니다.

Agent 1 → VM 1
Agent 2 → VM 2
Agent 3 → VM 3

이렇게 되면 사실상

AI 직원에게 컴퓨터를 지급하는 구조

가 됩니다.

이 개념 때문에 요즘 AI 커뮤니티에서는 이런 표현이 등장했습니다.

AI workforce

즉 여러 Agent가 각자 컴퓨터를 가지고 일을 하는 구조입니다.

Virtual Computer + LLM 구조

이제 중요한 질문이 하나 남습니다.

Agent의 두뇌는 무엇인가?

여기서 등장하는 것이 LLM 레이어입니다. 구조는 보통 이렇게 됩니다.

User
↓
Agent Orchestrator
↓
LLM
↓
Virtual Computer
↓
Tools / Browser / Code

여기서 LLM은

• - 계획 생성

• - 행동 결정

• - 결과 해석

역할을 합니다.

예를 들어 이런 작업이 있다고 해봅시다.

AI 스타트업 관련 블로그 글 작성

Agent는 이런 식으로 행동할 수 있습니다.

1 최신 뉴스 검색
2 자료 정리
3 글 작성
4 이미지 생성
5 블로그 배포

이 모든 행동을 결정하는 것이 LLM입니다.

즉 LLM + Virtual Computer 가 결합된 구조로 , AI가 OS역할을 하게끔 바뀝니다.

이제 말했던 내용들이

굉장히 미래적인 시스템처럼 보이지만 사실은 과거 컴퓨터 구조와 비슷합니다.

(현재) Human → Operating System → Computer

(미래) User → AI → Virtual Computer

로 바뀌고 있는 것입니다.

다시 돌아와서 비용에 대한 이야기를 해보도록 하겠습니다..

외부 LLM을 계속 사용하는것은 비싼데요. 흥미롭게도 최근 Agent 프로젝트들을 보면 점점 이런 흐름이 나타나고 있습니다.

외부 LLM → 자체 LLM

왜냐하면 Agent 시스템에서는 LLM이 단순 모델이 아니라 운영 시스템의 일부가 되기 때문입니다.

예를 들어 Agent는 계속 이런 작업을 합니다.

계획 생성
행동 결정
결과 분석
다음 행동 선택

이 과정은 생각보다 LLM 호출이 많습니다. 즉 구조적으로 이렇게 됩니다.

Agent loop
→ LLM call
→ Tool call
→ LLM call
→ Tool call

그래서 많은 회사들이 로컬 LLM과 대규모 LLM의 역할을 나눕니다. 바로 하이브리드 LLM 구조.

• Local LLM의 역할

• - task routing

• - tool selection

• - simple reasoning

• - summarization

Cloud LLM

• - complex reasoning

• - long writing

• - difficult tasks

예를 들어 Agent workflow는 이렇게 됩니다.

User request
↓
Local Llama model
↓
task plan
↓
tool execution
↓
complex step → GPT
↓
result

이 구조를 쓰면 LLM 호출의 70~80%를 로컬 모델이 처리할 수 있습니다.

Llama 기반 LLM을 로컬에 설치하는 이유

Llama 모델이 Agent 시스템에서 인기 있는 이유는 간단합니다.

설치가 쉽기 때문입니다.

예를 들어

Llama 3
Llama 3.1

로컬에서 바로 모델을 사용할 수 있습니다. 이 방식의 장점은 명확합니다.

비용과 latency를 아낄수있기 때문에 Agent loop가 훨씬 빨라집니다.

소규모 클라우드에서 Llama를 운영하는 방식

또 하나 흥미로운 방식은
작은 GPU 서버에 Llama를 올리는 구조입니다.

예를 들어

1 GPU server
→ 여러 Agent가 공유

구조입니다.

예

Agent cluster
↓
Llama inference server
↓
GPU

이 방식은 특히 스타트업에서 많이 사용합니다.

예를 들어

A10 GPU
L4 GPU

한 대로도 충분히 Agent 시스템을 운영할 수 있습니다.

그리고 이런 구조가 가능합니다.

1000 agent tasks
↓
local LLM
↓
cheap compute

즉 API 비용을 크게 줄일 수 있습니다.

실제로 많이 쓰는 구조

그래서 실제 Agent 시스템은
점점 이런 구조로 수렴하고 있습니다.

User
↓
Agent Orchestrator
↓
Local Llama Model
↓
Virtual Computer
↓
Tools

그리고 필요한 경우만

complex reasoning
↓
GPT / Claude

를 호출합니다.

이 구조의 핵심은 이것입니다.

LLM을 “API”가 아니라
시스템 컴포넌트로 사용한다

그래서 최종 정리합니다.

Agent 시스템이 커지면 LLM 호출 비용이 빠르게 증가합니다.

그래서 많은 팀들이 Llama 기반 모델을 로컬이나 소규모 클라우드에 설치하기 시작했습니다.

이 구조의 장점은 세 가지입니다.

1. 1. 비용 절감

API 호출 감소

2. 2. 속도 개선

Agent loop latency 감소

3. 시스템 통제

LLM을 인프라처럼 운영 가능

그래서 최근 Agent 아키텍처는 점점 이런 구조로 진화하고 있습니다.

Virtual Computer
+
Local LLM
+
Cloud LLM
+
Autonomous Agent

즉 AI 시스템은 더 이상 단순 모델이 아니라
여러 모델과 컴퓨팅 환경이 결합된 인프라가 되고 있습니다.